In packet-based systems, and in MPEG systems in particular, packets must be issued from play-out equipment in a correct order and at a correct time. Timing is important to avoid over-/under-flow in buffers of receiving equipment. Originating equipment, for example an encoder, maintains a model of a buffer of the receiving equipment and issues packets to an output of the originating equipment such that this buffer is kept sufficiently, but not overly, full. In MPEG video compression and transmission systems, this buffer is designed primarily for a video compression process itself and allows only minimally for timing disturbances that might occur in multiplexing and transmission. As MPEG systems have developed technically and have penetrated the market, demands on its use have changed, in particular in applications of MPEG in networks that are based on asynchronous packet methods, where special attention has to be placed on ensuring that relatively coarse transmission timing tolerances allowed in such networks can be managed.
Any multiplexing equipment must ensure that whatever a method of transmission, this packet timing is not unduly disturbed. In traditional multiplexing systems, packets are received on a number of input interfaces, timestamped upon receipt and played out with a least jitter possible, compatible with real-time multiplexing. Typically, in MPEG or similar video compression systems, one multiplexer outputs one or a small number of transport streams and these are all generated with reference to one master clock, usually with a clock frequency of 27 MHz in the case of MPEG2 or broadcast video systems.
In a quest for higher density, and with a transition to Ethernet/IP infrastructure, instead of an ASI format traditionally used within broadcast networks, single pieces of equipment handle more channels and are required to output many more transport streams than before. Within one piece of equipment, a number of different clock or timing sources exist, where in the past there was only one.
There is a requirement to provide a method whereby timestamps can be effectively passed between time reference domains, so as to facilitate multiplexing while introducing minimal jitter.
Referring to FIG. 1, in a multi-channel broadcast encoder 10, with, for example, four audio video encoders 11 in one piece of equipment, each encoder can be clock-locked to an incoming source clock 12, “video clock locked”, or the encoder can be locked to a system reference clock 13, sometimes referred to as locked to an HSYNC or black and burst signal. If all the encoders are locked to a system clock signal 13, then managing the process timing is quite simple, as there is only one clock. If, however, it is desired to run each encoder independently, then each one has its own timing reference and this must be allowed for in succeeding multiplexing stages.
In such multi-channel coding and/or multiplexing equipment, there is also likely to be a requirement for generation of multiple transport streams—some being single service, others being multiple service and hence consisting of differently timed sources.
Furthermore, it is necessary to consider a clock reference controlling a rate of these transport streams. FIG. 2 shows a multichannel broadcast encoder 20 with four audio video encoders 211-4 in parallel with outputs of a first encoder 211 and a second encoder 212 to a first multiplexer 241 and outputs of the first encoder 211, a third encoder 213 and a fourth encoder 214 to a second multiplexer 242. The first multiplexer 241 has a first output with a time-base TS1 and the second multiplexer 242 has a second output with a time-base TS2. Thus, referring to FIG. 2 it could be, for instance, that a first output with time-base TS1 is required, that is running at a first rate X Mbit/s clocked off a clock 22 of the first encoder 211 and consisting only of AV services from the first encoder 211 and second encoder 212 multiplexed together. A second output with time-base TS2 is also required, running at a second rate Y Mbit/s clocked off a clock of the fourth encoder 214 and consisting only of AV services output from the first encoder 211, the third encoder 213 and the fourth encoder 214 multiplexed together. Clearly a packet scheduling and play-out scheme is required that can cope with a diverse set of input and output time-bases.
It would be possible to achieve the required timing control using various Phase Locked Loop (PLL) arrangements such that accurate knowledge of one time-base can be maintained, while operating in another. Or, alternatively, using a very fast processor and sophisticated software that was able to monitor and manipulate all time-bases together.
Current best practice in solving this problem is to operate real time systems, whereby a previously sampled difference-value is subtracted from an instantaneous sample of a free-running time-base, to give a timestamp on a new time-base. This prior art process is illustrated by FIG. 3.
This method requires specialised hardware to implement, and requires multiple implementations of the hardware, one for each target time-base. Such hardware may, for example, consist of a PLL and a counter.
In a real-time system, a correct value exists at only one point in time, so this point must be well chosen. The system must also be ready to receive a packet at time x, and must sample both time-bases at the time the packet is received, for immediate processing. This implies multiple dedicated hardware.
The system does not account for drift between time-bases during a period a packet is held in the system. At low data rates this is a significant problem for best current practice as the time between timing markers is long thus leading to a greater risk of a large timing drift accumulating. What is required is a process that automatically takes account of such drift and so allows operation at lower bit rates than conventional methods.